Verifying check-in authentication by using an access authentication token

ABSTRACT

A simple and efficient means of checking the registration authorization is proposed by the method and the device for checking the registration authorization prior to the start of the re-registration process based on a registration query from a mobile radio terminal to at least one access device for an intra-domain handover in a mobile communication network. In the network, a token which has been sent by an access device to a mobile radio terminal and has been stored in at least one trust table of at least one access device, is received by at least one further access device during a registration query from a mobile radio terminal and compared with tokens stored in at least one trust table prior to the start of the registration for the purpose of verifying the registration authorization, and the registration is started if an authorization is present.

CLAIM FOR PRIORITY

This application claims priority to International Application No.PCT/EP02/10962, which was published in the German language on Sep. 30,2002.

TECHNICAL FIELD OF THE INVENTION

A method for defending against DoS attacks on optimized handoverprocedures, and in particular, which support quality of service aspectsusing regionally valid cryptographic authentication tokens.

BACKGROUND OF THE INVENTION

SUBRAMANYAM V ET AL: “Security in mobile systems” Reliable DistributedSystems, 1998, Proceedings, Seventeenth IEEE Symposium on WestLafayette, Ind., USA 20–23 Oct. 1998, Los Alamitos, Calif., USA, IEEEComput. Soc, US, Oct. 20, 1998 (1998–10–20), pages 407–412, XP010319125ISBN: 0-8186-9218-9, discusses requirements for mobility in a networkand the expansion of existing security schemes. For users, it can beimportant to have round-the-clock access to information in a network,even when they are mobile, for example, a doctor who constantly needs tomonitor the health of a patient. Communication in such cases typicallytakes place over wireless connections and it is difficult to guaranteesecurity during the exchange of messages. Typical objectives for securecomputing in the past were the archiving of confidentiality, integrity,availability, legitimacy and accountability.

Quality of Service (QoS) mechanisms guarantee service characteristics,such as the end-to-end run time, etc., in networks that support mobileInternet communication. In these networks, the mechanisms are exposed tothe threat of what are called “Denial of Service” (DoS) attacks aimed atreducing the availability of services for legitimized users. A threatresides in the fact that QoS signaling mechanisms are used to activatemobile nodes for queries to a network, which is equivalent to areservation of resources. If the network cannot effectively check the“credibility” of QoS queries, for example by querying the origin andauthorization of an query from a mobile node, the performance of thenetwork can be reduced due to bogus QoS queries. A mobile radio terminalleaves, for example, its home network and switches to a network withHMIPv6 interface and an AAA architecture. In the process, it is assumedthat a security association (SA) always exists between the mobilityanchor point (MAP) and each access router (AR), between the local AAAserver (AAAL) and each access router (AR), between the MAP and the AAAL,and between one access router and the other access routers. Once amobile radio terminal has successfully registered, its authenticationand authorization information (AA) is stored in a local AAA server(AAAL) and its identity is known to the MAP and to the access router(AR) with which the mobile radio terminal first registered. Thereafter,the mobile radio terminal can move between the coverage areas of theaccess routers (AR) without any interruption to a communication. Inorder to optimize the intra-domain handover, the waiting time (latency)for the registration with the individual access routers must beminimized as far as possible.

Generally, DoS attacks prevent or block normal usage or administrationof communication facilities (or other services). In most casesdenial-of-service (DoS) attacks have a specific objective. Thus, forexample, DoS attacks can cause the collapse or shutdown of the entirenetwork or a degradation of performance by overloading the network witha high number of transmitted bogus messages. All mobile radio terminalsin an access network can send QoS queries to all nodes along thecommunication path in order to reserve resources. This means thatattackers, too, can send QoS queries in the access network. For thisreason an access device, such as, say, an access router, must check the“credibility” of a QoS query from a mobile radio terminal before itprocesses the query further. If an access device does this with the aidof the local AAA server prior to the start of the reservation process,there is a significant waiting time for the re-registration process.When a mobile radio terminal switches from the coverage area of oneaccess router to the coverage area of a different access router in theaccess network (intra-domain handover), no interruptions should ensuebetween mobile radio terminal and access network. While the mobile radioterminal maintains the connection to the first access router, itinitiates a new registration process with a further access router bysending binding update (BU) messages. If no check is made beforehand toverify whether the mobile radio terminal is a registered user in theaccess network, attackers can overload the access network therewith, forexample by wasting computing capacity with queries concerningauthentication and authorization or by reserving resources for bogusqueries, etc.

SUMMARY OF THE INVENTION

The invention relates to a method and a device for checking theregistration authorization prior to the start of authentication andauthorization processes based on a registration query from a mobileradio terminal to at least one access device for an intra-domainhandover in a mobile communication network.

The present invention therefore guarantees optimum performance of thecommunication network by providing effective protection against bogusqueries.

In one embodiment of the invention, during an intra-domain handover,prior to the start of binding update and re-authentication andre-authorization processes (AAA processes), a check of the registrationauthorization takes place by means of an authentication token in orderto preempt DoS attacks. The advantages of this method are a shortwaiting time for re-registration processes and effective protectionagainst DoS attacks. By means of this method it is possible to avoid thememory of the access router being filled as a result of a DoS attack(the DoS attack attempts to fill the memory of the system under attackand thereby render the system unable to accept any further legitimatequeries), the performance of the signaling capacity in the accessnetwork being degraded due to bogus queries, and the unauthorizedseizing of resources in the local AAA server by bogus queries. Thereduction of the risks by repeated transmission of authenticationtokens, such as a cookie for example, can be achieved on the basis of atightly limited area of validity in which the token is accepted.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be explained in more detail below with reference toexemplary embodiments represented in the drawings, in which:

FIG. 1 shows how the first token is sent to the mobile radio terminal.

FIG. 2 shows how the previously generated token is sent to a furtheraccess device without limitation of the area of validity and without ausage indicator.

FIG. 3 shows how the previously generated token is transmitted without ausage indicator in a limited area of validity.

FIG. 4 shows how the previously generated token is transmitted with ausage indicator in a limited area of validity.

FIG. 5 shows how a token is sent to a mobile radio terminal following anintradomain handover.

FIG. 6 shows a schematic for a device for sending and checking tokens.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 shows how the mobile radio terminal 5 sends a first registrationquery to an access router 4 when it (5) is switched on or when it (5)first registers with the access network. Once the local AAA server hasreceived the positive authentication and authorization information fromthe home AAA server, it informs the mobility anchor point (MAP) 2 of thesuccessful authentication and authorization check. The mobility anchorpoint (MAP) 2 then sends the session key which was generated by the homeAAA server and forwarded with the authentication and authorizationinformation to the access router 4 so that the access router can set upa security association with the mobile radio terminal 5. The accessrouter 4 generates a token, encrypts it by means of the session key, andsends it to the mobile radio terminal 5. The mobile radio terminal 5receives the session key safely from the home AAA server with the aid ofa long-term security association.

Here, tokens are always generated by an access router. The mobile radioterminal 5 receives the first token from the access router with whichthe mobile radio terminal 5 registers or performs an intra-domainhandover, i.e. after successful registration the token encrypted bymeans of the session key is established between the mobile radioterminal 5 and access routers of the access network and transmitted byan access router 4 to the mobile radio terminal 5 together with thebinding update message. Each access router 4 has at least one trust list7. In one trust list 7 (trusted list) information is stored concerningthe access routers 1, 6 whose tokens will be accepted, and in adifferent trust list 7 (trusting list) information is stored about theaccess routers 1, 6 which will accept the tokens of the generatingaccess router 4. The tokens already used can be stored in a third trustlist 7. This is where the tokens which have already been successfullyused once by a mobile radio terminal are stored. By this means, it isensured that a token is “invalidated” after a one-time use and cannot beused repeatedly. The purpose served by the two other trust lists is thateach token used does not need to be stored in every access router 1, 4,6 of the entire access network, but only in the access routers 1, 4, 6which reside in the areas of validity implemented by means of the twotrust lists (trusted list and trusting list). Without the restriction onthe area of validity the method would not scale for large accessnetworks. It accepts tokens that have been generated by the accessrouters 4 which are included in its trust list. A further trust list 7includes the access routers which will accept the tokens generated bythis access router 4. In order to increase security, an access router 4stores the tokens of its neighboring access routers in a trust list. Inthis way, a limited area of validity is created for the acceptance of atoken, since an access router 4 accepts its own self-generated tokensand those generated by a neighboring access router 6.

When a mobile radio terminal 5 wants to perform an intra-domainhandover, it (5) adds the token of the re-registration query and (5)sends it as text to the new access router 6. The new access router 6executes three actions in order to check the token:

-   -   Check of the term of validity for the expiry time of the token;    -   Check, by reference to a trust list 7, of the identity of the        access router which generated the token;    -   Following the check of the aforementioned points, a random        number suffix (key-hashed digest) is computed with the token        information using the token key and compared with the key-hashed        digest already present in the token.

If the check on the token is successful, the binding update andre-authorization processes are launched. The new access router 6 willauthenticate the re-registration query when it receives the session keywhich is included in the re-registration query (BU ACK message) from themobility anchor point (MAP) 2. If the verification fails, the accessrouter 6 will not process the re-registration query any further. If,after a certain delay, the mobile radio terminal 5 has still notreceived any response regarding the re-registration of the access router6, the mobile radio terminal 5 starts an authorization andauthentication process via the local AAA server 3 and the home AAAserver, as in the case of an intradomain handover or when the device 5is switched on. As a result, however, it (5) cannot use the optimizedhandover process.

A new token is generated with the session key by the access router 6 andsent to the mobile radio terminal 5 for the next intra-domain handover,provided the re-authentication process did not fail. The old tokencannot be re-used. Following verification of the token, the accessrouter 6 informs the access router 4 which generated the token about theuse of the token. The access router 4 which generated the token informsthe access routers 1, 6 in its trust lists 7, except for the accessrouter 6 which used the token, in order to prevent a second use of thetoken. When the token reaches its expiry time for the validity of thetoken, the token is deleted from the trust lists 7 of the access routers1, 4, 6. A token includes the token information and the key-hasheddigest (hash code). The token information includes:

-   -   The identity of the mobile radio terminal 5: the one-time        identification of the mobile radio terminal 5 in the access        network; this can be a unique identification which a mobile        radio terminal 5 receives after its first registration.    -   The identity of the access router which generated the token: The        one-time (=only used once, unique) access router identification        can be its IP address or some other unique means of        identification in the access network.    -   The generation time for creation of the token is used to limit        the term of validity of the token.    -   A random number: This is used in order to differentiate two        tokens that were generated at the same time.

A key-hashed digest message is an extract from the token information andthe token key. The key-hashed digest can be computed either by thefunction HMAC-MD5 or by the function FIMAC-SHA1. The token key isdistributed to each access router by the mobility anchor point (MAP) 2and periodically updated.

A token therefore looks as follows:

Token:=token information, token key-hashed digest

Token information:=(identity of the mobile radio terminal, identity ofthe generating

access router, generation time, random number)

Token key-hashed digest:=HMAC (token key, token information)

FIG. 2 shows the case where the area of validity for a generated tokenis the entire access network. When a token is sent to an access router 6for its first use, it (6) is safe from DoS attacks since it (6) is theone that knows that the token has been used and so it (6) can prevent asecond use of the token. Other access routers 1, 4 which have noinformation about the use of the token could be in danger of notnoticing a DoS attack because the access router 6 has not passed on theinformation about the use of the token in the access network. On theother hand, passing the information about the use of the token to theentire access network causes a very great deal of signaling traffic inthe access network.

FIGS. 3 and 4 show how each access router enters its two neighboringaccess routers and itself in at least one trust list in order to reducethe area of validity of the token. For example, access router 4 entersthe access routers 1 and 6 and itself in at least one trust list. Thisensures that the token generated by the access router is accepted by theaccess routers 1, 4 and 6. The access router 4 possesses securityassociations with the access routers 1, 6, and each access router 4, 1and 6 has at least one trust list 7 including information whichindicates which tokens it (4) will accept from which access routers 1, 4and 6.

The mobile radio terminal 5 receives a token generated by the accessrouter 4 and sends it to an access router 6 for an intra-domainhandover. Following successful checking of the token the binding updateand AAA processes start. The access routers that are not included in thetrust list 7 of the access router 4 (e.g. all other access routersexcept 1, 4 and 6) are not in danger of receiving a repeated token whichhas already been used. The access router 6 which used the token is alsoaware of its use, i.e. only the access routers 1 and 4 are still at riskin the event of any DoS attack, as they would still accept this token.

FIG. 5 shows how the access router 6, after it (6) has accepted thetoken, immediately sends information to the access router 4 whichgenerated the token. The access router 4 then informs the access router1 in its trust list 7 and the access router 6 so that the latter 6 willaccept no further copies of the token.

If the check on the token fails, the re-registration process will not bestarted. Otherwise, it is started simultaneously with the binding updateprocess and the re-authorization process. When a re-registration query(BU ACK message) including the session key arrives at the access router6, the latter (6) checks a digital signature which was created by amobile node over the entire run time of the QoS query including thesession key in relation to the re-authentication. Following a successfulcheck of the token the access router 6 adds a new token encrypted bymeans of the session key to the re-registration query (BU ACK message)and sends it to the mobile radio terminal 5.

FIG. 6 shows how an access router 4 generates a token by means of aprocessing unit 11 and sends it by means of a transmitter unit 12 to amobile radio terminal. Tokens that have been generated by further accessrouters 6 are forwarded via a receiver unit 10 to a processing unit 11,which sends them to a further trust list 7. Each access router (4, 6)has at least one trust list. Information about the access routers (1, 6)whose tokens will be accepted is stored in a trust list 7 (trustedlist), while information about the access routers (1, 6) which willaccept the tokens of the generating access router (4) is stored inanother trust list 7 (trusting list). The already used tokens are storedin a third trust list 7. In this list are stored tokens which havealready been successfully used once by a mobile radio terminal. If amobile radio terminal 5 wants to perform an intra-domain handover, it(5) adds the token to the re-registration query and (5) sends it as textto the new access router 6. The new access router 6 receives the tokenvia a receiver unit 10 and forwards it for checking to a processing unit11. The processing unit 11 executes three actions in order to check thetoken:

-   -   Checks the period of validity for the expiry time of the token;    -   Checks, by consulting a trust list 7, the identity of the access        router which generated the token;    -   Following the two aforementioned checks, a random number suffix        (key-hashed digest) is computed with the token information using        the token key and compared with the key-hashed digest which is        already present in the token.

If the token check is successful, the binding update andre-authorization processes are started. The new access router 6 willauthenticate the re-registration query if it receives the session keywhich is contained in the re-registration query (BU ACK message) fromthe mobility anchor point (MAP) 2 via a receiver unit 10. If theverification fails, the access router 6 will not process there-registration query any further. If the mobile radio terminal 5 hasstill not received an answer about the re-registration from the accessrouter 6 via a transmitter unit 12 after a certain time, the mobileradio terminal 5 must start an authorization and authentication processvia the local AAA server 3 and the home AAA server, as in the case of anintra-domain handover or when the device 5 is switched on.

1. A method for checking the registration authorization prior to a startof a re-registration process based on a registration query from a mobileradio terminal to at least one access device for an intra-domainhandover in a mobile communication network, comprising: receiving atoken, which has been sent by an access device to a mobile radioterminal and has been stored in at least one trust table of at least oneaccess device, by at least one further access device during aregistration query from a mobile radio terminal; comparing the receivedtoken with tokens stored in the at least one trust table prior to thestart of the registration to verify the registration authorization; andstarting the registration if the registration authorization is verifiedand the token is invalidated after one-time use and is not usedrepeatedly.
 2. The method according to claim 1, wherein the token isencrypted by means of a key and transmitted to a mobile radio terminal.3. The method according to claim 1, wherein the registrationauthorization check is performed prior to the start of there-registration processes.
 4. The method according to claim 1, whereinthe binding update process is used for the re-registration process. 5.The method according to claim 1, wherein the authentication andauthorization process is used for the re-registration process.
 6. Themethod according to claim 1, wherein the authentication andauthorization process and a binding update process are usedsimultaneously for the re-registration process.
 7. The method accordingto claim 1, wherein at least one access device is an access router. 8.The method according to claim 1, wherein renewal of a binding process isstarted following successful checking of the authorization by the atleast one access device.
 9. The method according to claim 1, whereinrenewal of the authorization and authentication process is startedfollowing successful checking of the authorization by the at least oneaccess device.
 10. The method according to claim 1, wherein the token issent with a message for renewal of a binding between the at least oneaccess device and the mobile radio terminal.
 11. The method according toclaim 1, wherein the at least one access device sends the token receivedfrom the mobile radio terminal to a neighboring access device.
 12. Themethod according to claim 1, wherein the at least one access devicesends the token received from the mobile radio terminal to a neighboringaccess device which is stored in a trust list.
 13. The method accordingto claim 1, wherein the at least one access device stores tokensreceived from neighboring access devices in the at least one trusttable.
 14. The method according to claim 1, wherein used tokens arestored in the trust table.
 15. The method according to claim 1, whereinthe mobile radio terminal sends the token to a further of the at leastone access devices during an intra-domain handover.
 16. The methodaccording to claim 1, wherein a further of the at least one accessdevices checks the token according to a period of validity of the token.17. The method according to claim 1, wherein a further of the at leastone access devices checks the token according to generation of thetoken.
 18. The method according to claim 1, wherein a token suffixrepresenting a key is compared with a key computed by the at least oneaccess device.
 19. The method according to claim 1, wherein a tokenincludes an identity of the mobile radio terminal.
 20. The methodaccording to claim 1, wherein a token includes an identity of the accessdevice generating the token.
 21. The method according to claim 20,wherein the token includes a generation time.
 22. The method accordingto claim 20, wherein the token includes a random number.
 23. The methodaccording to claim 20, wherein the token includes a digest representinga key.
 24. A device for checking the access authorization at a starttime of authentication and authorization processes based on aregistration query from a mobile radio terminal to at least one accessdevice for an intra-domain handover in a mobile communication network,comprising: a receiver unit to receive a token and a query concerningthe authorization for access by a mobile radio terminal; a processingunit to generate tokens which are invalidated after one-time use and isnot used repeatedly and to check received tokens; at least one trusttable to store generated tokens and tokens received by at least oneaccess device; and a transmitter unit to send generated tokens to themobile radio terminal and at least one further access device and toforward the access authorization to further network units.